Static Application Security Testing of Consensus-Critical Code in the Cosmos Network

Blockchains require deterministic execution in order to reach consensus. This is often guaranteed in languages designed to write smart contracts, such as Solidity. Application-specific blockchains or ``appchains'' allow the blockchain application logic to be written using general-purpose programming languages, giving developers more flexibility but also additional responsibilities. In particular, developers must ensure that their blockchain application logic does not contain any sources of non-determinism. Any source of non-determinism may be a potential source of vulnerabilities. This paper focuses on the use of Static Application Security Testing (SAST) tools to detect such sources of non-determinism at development time. We focus on Cosmos, a prominent open-source project that lets developers build interconnected networks of application-specific blockchains. Cosmos provides a Software Development Kit (SDK) that allows these chains to be implemented in the Go programming language. We create a corpus of 11 representative Cosmos-based appchains to analyze for sources of non-determinism in Go. As part of our study, we identified cosmos-sdk-codeql, a set of CodeQL code analysis rules for Cosmos applications. We find that these rules generate many false positives and propose a refactored set of rules that more precisely detects sources of non-determinism only in code that runs as part of the blockchain logic. We demonstrate a significant increase in the precision of the rules, making the SAST tool more effective and hence potentially contributing to enhanced security for Cosmos-based blockchains.Comment: 5th Conference on Blockchain Research & Applications for Innovative Networks and Services (BRAINS'23

Fork/Join Parallelism in the Wild: Documenting Patterns and Anti-Patterns in Java Programs using the Fork/Join Framework

Now that multicore processors are commonplace, developing parallel software has escaped the confines of high-performance computing and enters the mainstream. The Fork/Join framework, for instance, is part of the standard Java platform since version 7. Fork/Join is a high-level parallel programming model advocated to make parallelizing recursive divide-and-conquer algorithms particularly easy. While, in theory, Fork/Join is a simple and effective technique to expose parallelism in applications, it has not been investigated before whether and how the technique is applied in practice. We therefore performed an empirical study on a corpus of 120 open source Java projects that use the framework for roughly 362 different tasks. On the one hand, we confirm the frequent use of four best-practice patterns (Sequential Cutoff, Linked Subtasks, Leaf Tasks, and avoiding unnecessary forking) in actual projects. On the other hand, we also discovered three recurring anti-patterns that potentially limit parallel performance: sub-optimal use of Java collections when splitting tasks into subtasks as well as when merging the results of subtasks, and finally the inappropriate sharing of resources between tasks. We document these anti-patterns and study their impact on performance

Modularity and Conventions for Maintainable Concurrent Language Implementations: A Review of Our Experiences and Practices

In this paper, we review what we have learned from implementing languages for parallel and concurrent programming, and investigate the role of modularity. To identify the approaches used to facilitate correctness and maintainability, we ask the following questions: What guides modularization? Are informal approaches used to facilitate correctness? Are concurrency concerns modularized? And, where is language support lacking most? Our subjects are AmbientTalk, SLIP, and the RoarVM. All three evolved over the years, enabling us to look back at specific experiments to understand the impact of concurrency on modularity. We conclude from our review that concurrency concerns are one of the strongest drivers for the definition of module boundaries. It helps when languages offer sophisticated modularization constructs. However, with respect to concurrency, other language features like single-assignment are of greater importance. Furthermore, tooling that enables remodularization taking concurrency invariants into account would be of great value

Domains: safe sharing among actors

The actor model is a concurrency model that avoids issues such as deadlocks and data races by construction, and thus facilitates concurrent programming. While it has mainly been used for expressing distributed computations, it is equally useful for modeling concurrent computations in a single shared memory machine. In component based software, the actor model lends itself to divide the components naturally over different actors and use message-passing concurrency for the interaction between these components. The tradeoff is that the actor model sacrifices expressiveness and efficiency with respect to parallel access to shared state. This paper gives an overview of the disadvantages of the actor model when trying to express shared state and then formulates an extension of the actor model to solve these issues. Our solution proposes domains and synchronization views to solve the issues without compromising on the semantic properties of the actor model. Thus, the resulting concurrency model maintains deadlock-freedom and avoids low-level data races

Tanks: Multiple reader, single writer actors

In the past, the Actor Model has mainly been explored in a distributed context. However, more and more application developers are also starting to use it to program shared-memory multicore machines because of the safety guarantees it provides. It avoids issues such as deadlocks and race conditions by construction, and thus facilitates concurrent programming. The tradeoff is that the Actor Model sacrifices expressiveness with respect to accessing shared state because actors are fully isolated from each other (a.k.a. "shared-nothing parallelism"). There is a need for more high level synchronization mechanisms that integrate with the actor model without sacrificing the safety and liveness guarantees it provides. This paper introduces a variation on the communicating event-loops actor model called the Tank model. A tank is an actor that can expose part of its state as a shared read-only resource. The model ensures that any other actor will always observe a consistent version of that state, even in the face of concurrent updates of the actor that owns that state

Domains: Sharing State in the Communicating Event-Loop Actor Model

The actor model is a message-passing concurrency model that avoids deadlocks and low-level data races by construction. This facilitates concurrent programming, especially in the context of complex interactive applications where modularity, security and fault-tolerance are required. The tradeoff is that the actor model sacrifices expressiveness and safety guarantees with respect to parallel access to shared state. In this paper we present domains as a set of novel language abstractions for safely encapsulating and sharing state within the actor model. We introduce four types of domains, namely immutable, isolated, observable and shared domains that each are tailored to a certain access pattern on that shared state. The domains are characterized with an operational semantics. For each we discuss how the actor model's safety guarantees are upheld even in the presence of conceptually shared state. Furthermore, the proposed language abstractions are evaluated with a case study in Scala comparing them to other synchonisation mechanisms to demonstrate their benefits in deadlock freedom, parallel reads, and enforced isolation

Towards an Actor-based Concurrent Machine Model

In this position paper we propose to extend an existing delegation-based machine model with concurrency primitives. The original machine model which is built on the concepts of objects, messages, and delegation, provides support for languages enabling multi-dimensional separation of concerns (MDSOC). We propose to extend this model with an actor-based concurrency model, allowing for both true parallelism as well as lightweight concurrency primitives such as coroutines. In order to demonstrate its expressiveness, we informally describe how three high-level languages supporting different concurrency models can be mapped onto our extended machine model. We also provide an outlook on the extended model's potential to support concurrency-related MDSOC features

Effect of HIV-1 infection on T-Cell-based and skin test detection of tuberculosis infection

RATIONALE: Two forms of the IFN-gamma release assay (IFNGRA) to detect tuberculosis infection are available, but neither has been evaluated in comparable HIV-infected and uninfected persons in a high tuberculosis incidence environment. OBJECTIVE: To compare the ability of the T-SPOT.TB (Oxford Immunotec, Abingdon, UK), QuantiFERON-TB Gold (Cellestis, Melbourne, Australia), and Mantoux tests to identify latent tuberculosis in HIV-infected and uninfected persons. METHODS: A cross-sectional study of 160 healthy adults without active tuberculosis attending a voluntary counseling and testing center for HIV infection in Khayelitsha, a deprived urban South African community with an HIV antenatal seroprevalence of 33% and a tuberculosis incidence of 1,612 per 100,000. MEASUREMENTS AND MAIN RESULTS: One hundred and sixty (74 HIV(+) and 86 HIV(-)) persons were enrolled. A lower proportion of Mantoux results was positive in HIV-infected subjects compared with HIV-uninfected subjects (p < 0.01). By contrast, the proportion of positive IFNGRAs was not significantly different in HIV-infected persons for the T-SPOT.TB test (52 vs. 59%; p = 0.41) or the QuantiFERON-TB Gold test (43 and 46%; p = 0.89). Fair agreement between the Mantoux test (5- and 10-mm cutoffs) and the IFNGRA was seen in HIV-infected people (kappa = 0.52-0.6). By contrast, poor agreement between the Mantoux and QuantiFERON-TB Gold tests was observed in the HIV-uninfected group (kappa = 0.07-0.30, depending on the Mantoux cutoff). The pattern was similar for T-SPOT.TB (kappa = 0.18-0.24). Interpretation: IFNGRA sensitivity appears relatively unimpaired by moderately advanced HIV infection. However, agreement between the tests and with the Mantoux test varied from poor to fair. This highlights the need for prospective studies to determine which test may predict the subsequent risk of tuberculosis

A phase I radiation dose-escalation study to determine the maximal dose of radiotherapy in combination with weekly gemcitabine in patients with locally advanced pancreatic adenocarcinoma

<p>Abstract</p> <p>Background</p> <p>The primary objective of this study was to determine the maximum tolerated dose (MTD) of escalating doses of radiotherapy (RT) concomitantly with a fixed dose of gemcitabine (300 mg/m²/week) within the same overall treatment time.</p> <p>Methods</p> <p>Thirteen patients were included. Gemcitabine 300 mg/m²/week was administered prior to RT. The initial dose of RT was 45 Gy in 1.8 Gy fractions, escalated by adding 5 fractions of 1.8 Gy (one/week) to a dose of 54 Gy with a total duration kept at 5 weeks. All patients received a dynamic MRI to assess the pancreatic respiratory related movements. Toxicity was scored using the RTOG-EORTC toxicity criteria.</p> <p>Results</p> <p>Three of six patients experienced an acute dose limiting toxicity (DLT) at the 54 Gy dose level. For these patients a grade III gastro-intestinal toxicity (GI) was noted. Patients treated at the 45 Gy dose level tolerated therapy without DLT. The 54 Gy dose level was designated as the MTD and was deemed not suitable for further investigation.</p> <p>Between both dose levels, there was a significant difference in percentage weight loss (p = 0.006) and also in cumulative GI toxicity (p = 0.027). There was no grade 3 toxicity in the 45 Gy cohort versus 4 grade 3 toxicity events in the 54 Gy cohort. The mean dose to the duodenum was significantly higher in the 54 Gy cohort (38.45 Gy vs. 51.82 Gy; p = 0.001).</p> <p>Conclusion</p> <p>Accelerated dose escalation to a total dose of 54 Gy with 300 mg/m²/week gemcitabine was not feasible. GI toxicity was the DLT. Retrospectively, the dose escalation of 9 Gy by accelerated radiotherapy might have been to large. A dose of 45 Gy is recommended. Considering the good patient outcomes, there might be a role for the investigation of a fixed dose of gemcitabine and concurrent RT with small fractions (1.8 Gy/day) in borderline resectable or unresectable non-metastatic locally advanced pancreatic cancer.</p